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Streaming Server Administration Protocol 

Field of Invention 

The present invention relates generally to protocols and more particularly to 
a network based administration protocol. 

Background of the Invention 

Server administrators have traditionally used operating system commands, 
calls and functions to obtain internal server data. With these commands, the server 
administrator can typically display the seryer status, display the number of current 
connections and the detailed information for each connection, display the 
configuration options for the server, display the configuration options for each server 
module extension, modify the configuration options for server and module extension, 
display all server module extensions, display real-time statistics for the server, for 
example, average number of connections, what streaming applications are being 
selected and their frequency of selection, the current number of connections and 
bandwidth used, and display the entire server state for debugging and servicing of 
problems. 

Examples of such configuration options referred to above include, the 
maximum number of connections allowed, the default server directory or list of 
directories, the maximum or minimum buffer size, the time interval for a process or 
function, the time duration for a process or function, error messages, enable or 
disable features, a file or list of files for a feature, or a user or list of users for a 
feature. 
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For example, based on the real-time number of connections returned by a 
streaming server, a web server can dynamically create URL's to different streaming 
servers to load balance across multiple servers or networks. In another example, 
based on the real-time file access returned by a streaming server, a web server 
providing an access page to the streaming servers can dynamically create browser 
URL's to allow, deny, or redirect access to different streaming files to load balance 
or control access to users. 

Traditional tools available to server administrators, however, require a specific 
command or network request for a specific data element or set or set of data elements. 
In most cases, additional data access requires additional commands and changes to the 
server and administrator software. One disadvantage of a direct mapping between 
command and data is the lack of the ability for data discovery and a rigid connection 
between a particular tools 's code and the server data it can retrieve, display or 
process. Furthermore, these tools generally consume server resources when run. 
The resource allocation for these tools may disadvantageous^ effect the performance 
of other applications running on top of the server operating system. When a server 
is streaming data into a computer network for transmission to the client, such 
limitations on the performance of the streaming application may disadvantageous^ 
result in the interruption of streaming data. For example, in a streaming video 
application, the interruption of data may result in perceptible distortion or pausing 
of a video image displayed on a user device connected to the network. 

It would be desirous to provide a network software application like a streaming 
server which would allow server administrators to access server data from any user 
device in a network. It would be further desirous to provide a streaming server which 
would allow server administrators to access such data remotely in real time. It would 
be advantageous to software creators to provide a server data administration feature 



-3- 

requiring a minimum of software changes to existing HTTP based software tools in 
order to gather information, change information or work with new information stored 
in a network software application 

Summary of the Invention 

It is an object of the present invention to overcome one or more disadvantages 
and limitations of the prior art herein above enumerated. 

It is a further object of the present invention to allow a single mechanism to 
add, set, delete or retrieve any required server data value. 

It is yet another object of the present invention to use a query mechanism that 
defines an array iterator and name lookup. 

It is still a further object of the present invention to allow for data discovery 
and retrieval of specific data elements. 

According to the present invention, a novel protocol is implemented in a 
streaming server module for real time access to network software data from any 
location within a computer network in which the server resides. The novel protocol 
supports the use of standard network software programs like web server CGIs and 
HTTP client software like web browsers for accessing the data from any user device 
connected to the network or local to the server. The internal network software data 
structures are modified using the invention's protocol syntax to support a connected 
network client software program. The protocol relies on upon the URI mechanism 
for specifying a container entity using a path, and HTTP 1.0 for specifying request 
and response mechanisms. The goal of the protocol is to remove the usual 
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administration protocol mapping between a command and the data it references, and 
replace this function with a simple HTTP based command with a URI formatted data 
specifier 



A feature of the present invention is that the server data is obtainable remotely 
through the network or locally at the server. A further feature of the present 
invention is that the administration protocol does not require network transport 
support. 

Still further features of the present invention are the ability to provide within 
the protocol password protected access to the server data whether accessed locally or 
remotely and multiple simultaneous administrator requests. Another feature is that 
the protocol allows data discovery and retrieval with various data types, for example, 
character, integer and floating point. 

Yet further features Of the protocol of the present invention is the ability to 
provide read and write permissions to the information provided by the access to the 
server data, and the ability to mofchfy the server state such as session., server and 
preferences. \ 

Still further features are that the request and response for server data is 
formatted as an HTTP GET request and response. The response data from the server 
may also be HTML or XML formatted. 

Additional features of the present invention is that the protocol allows for 
specific data requests of server data, server side data filtering, setting of server 



attributes, adding, removing and setting server data elements and values, and multiple 
filters per request for data coherency and performance. 



(\\^f These and other otJJ^cts advantages and features of the present invention will 
^ pecome apparent to those skillbd in the art from a study of the following Description 
5 of the Exemplary Preferred Embodiments when read in conjunction with the attached 
drawing and appended Claims. 



Brief Description of the Drawing 



Fig. 1 is a schematic block diagram of a network constructed according to the 
principals of the present invention. 

10 Fig. 2 is a flow chart of an exemplary process of the present invention. 

Description of the Exemplary Preferred Embodiments 

Referring now^P Fig. 1, there is shown a computer network 10 constructed 
according to the principle^of the present invention. Network 10 includes a server 12 
and a client 14. the commmiication between the server 12 and the client 14 may be 
15 either directly connected or tnrough another medium 16, which may be any of a local 
area network, wide area netwVk, the Internet, or any other proprietary or public 
network. Each of the server 12 ami client 14 respectively have associated therewith a 
computer readable medium 18, 20,\br storing of programs which implement the 
processes, procedures and methods of tnte herein below described inventive protocol. 




20 With reference to Fig. 2, the server 12 receives an HTTP path name, as 

indicated at 30. At 32, a decision is made whether an administrative module is 



identified in the path name. If not and the path name identifies, for example, a typical 
HTML page, the server would send the HTML page, as indicated at 34. If yes, as 
indicated at 36, the server 12 process the novel protocol of the present invention, as 
described in detail herein below. After processing the HTTP path name identifying an 
administrative module, the administrative data is sent to the client 14, as indicated at 
38. 

The novel protocol of the present invention support use of CGI's or HTTP 
client software to develop monitoring and administration software to obtain server 
data of the type particularly useful to server administrators. To implement such a 
protocol, abstraction from the internal server data structure of the server on which the 
protocol resides is required as well as changes to such internal data structure, to 
support the requests described in greater detail herein below. 

The novel protocol of the present invention also allows for network or local 
access by server administrators to internal server data. The protocol does not require 
network transport support. The protocol of the present invention relies upon the URI 
mechanism as defined by RFC2396 for specifying a container entity using a path and 
HTTP 1.0 RFC 1945 for specifying request and response mechanisms. 

More specifically, access to internal server data may be obtained through 
client software by using the familiar path name of a URL in conventional client 
software, wherein the path name specifies a container from which such data may be 
obtained. For example, a path name may be written as URL/module/admin/, wherein 
module/admin/ is the container. It will become readily apparent from the description 
herein below that the use of the URL can retrieve data from various levels of 
container data. The protocol of the present invention in addition to supporting the 
URL path name, also supports CGI scripting at the server so that commands may be 
added to the path name. 



More specifically, requirements for the implementation of the novel protocol 
of the present invention are described herein below with respect to specific headings. 
For clarity and to enable those skilled in the art to practice the present invention, the 
syntax of the URI is also provided. Reference is made to the Drawing figures to give 
examples of various requests and responses using herein described protocol. 

Request Methods 

HTTP GET is the primary request method. HTTP POST can be used to 
perform multiple data requests. 

Session State 

The session is closed at the end of each HTTP request response. 
Evaluation of POST 

A POST Request-URI with a query parameter of command = SET is a set of 
server data. Body name = "value" pairs are required and evaluated as discrete sets. 

A POST Request-URI without a query parameter or a query parameter of 
command = GET is evaluated as a get of a data name or value. Body URL filters are 
not required. 

Request Header Features 

Authorization 

If-Modified-Since 

Specifying Server Data 

All data on the server is specified using an URI 



Definition of Server URL 



Administration URL references directed to the server must specify the 7qtss" 
base segment and the admin module "/admin". The path names are significant for 
routing the request to the appropriate request handler. 

For example, http://server:port/qtss/admin, references the qtss admin module 
which implements the admin protocol 

URI Requests 

Always absolute references beginning with the Server URL 
rule: 

[absolute URL] ? [parameters = "value(s)"] + [option = "value"] + 
[op tion= "value"] 
example: 

/qtss/admin/server/sessions?parameters =rva+ snapshots = "value" 
URI Rules 

/path = absolute reference 
path = relative reference 

path/ = / is defined as any container in the "path" reference 

* = iterate each element in the current location 

path/* = is defined as all elements contained in the "path" reference 

. = not supported 

. . = not supported 

; = not supported 

? = query options follow (" + " delimited name =" value" pairs) 
spaces and tabs = stop characters 

= are supported from values and required for values containing spaces and 

tabs. 
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Path Definition 

A path represents a virtual hierarchical data structure of containers and is 
expressed as a URL. The path terminates with an element. The terminating element 
may be a container. 

Elements are arrays. If there is a single element in the array, then the 
following URL queries are equivalent: "path/element", "path/element/", 
"path/element/*", and " path/element/ 1" are all evaluated as the same query. 

Query Options 

A URI without a '?' defaults to a GET request 
example: /qtss/admin/server/sessioncount 

A URI containing a '?' designator must contain a "command =thecommand" 
query option. 

example : /qtss/admin/server/sessioncount?command = GET 

Query options are not case sensitive. Query option values are case sensitive. 
Unknown query options are ignored. Query options not required by a command are 
ignored. 

command option: 

command = [GET | SET | DEL | ADD] 
Unknown command are reported as an error. 

command=GET <- get data identified by URI. ( H <-" = comment) 
The GET does not require other query options 
Example: GET /qtss/admin/maxcount 



command = SET <- set data identified by URI 
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The command sets the element value referenced by the URL. The required 
query options are value = 

value checking is not performed. Conversion between the text value and the 
actual value is type specific. 
5 Example : GET /qtss/admin/maxcount?command = SET + value = 5 




optional query options for the SET command 

type= < - iKlefined then type checking of the server element type and the set 
ype is performed. If a>match of the stored type and the request type fails, an error 
is returned an the commaiKkfails. 
10 Example: 

GET /qtss/admin/maxcount?command = SET + value = 5 + type = SInt32 

command = DEL < - delete data identified by the URL The command deletes 
the element referenced by the URL. Example: 

GET /qtss/admin/maxcount?command = DEL 

15 command = ADD < - add data identified by the URL If the element at the end 

of the URL is an element the ADD performs an add to the array of elements 
referenced by the element name. 

Required query options are: value = and type = 

example: GET /qtss/admin/maxcount ? command = ADD + value =6 
20 +type=SInt!6 + access = rw 



type= 



optional query options for the ADD command are: access = 
example: GET /qtss/admin/ ? command = ADD -I- value =5 4- name 
SIntl6 + access =rw 



=maxcount 
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If the element at the end of the URL is a QTSS_Object container, then an 
ADD performs a named element add to the container. Required query options in this 
case are: value = , type= and name=. Example: GET /qtss/admin/ ? 
command = ADD + value =5 + name =maxcount type = SInt 16 

5 parameter options: 

r = recur se -. walk downward in hierarchy (path?parameters = r and 
path/*?parameters=r are evaluated as the same query) 
v = verbose - > return full path in name 
a = access - > return read/write access 
10 t = type - > return type of value 

d = debug - > return debugging info with error 
c = count - > return count of elements in path 

Parameters are always single characters with no delimiters. Parameter options 
follow the URL, e.g., [URL]?parameters = [p][p], 
1 5 example path/path?parameters = rvat 



Data T\ 




Data types^can be any server allowed text value. New data types can be 
defined and returned dy the server. The data types are: Uint8, Sint8, Uintl6, Sintl6, 
Uint32, Sint32, Uint64\Sint64, Float32, Float64, B00I8, B00II6, CharArray, 
20 QTSS_Object, and void_pomter. QTSSObjects, pointers and unknown data types 
always convert to a host ordered! hex value. The values converted are returned in 
hex. AN example is when adding\ new attribute to the server. If the type is not 
known by the server, then the value returned will be a string of hex values. 



Snapshots 
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A snapshot fs the container of values from which an admin response is 
generated (the measureii values at a particular point in time, as compared to the 
constantly changing values)*. There is one active snapshot per admin connection. 
Each request without a snapshot in the URI generates a new snapshot. There is only 
one current snapshot per requests. Each new snapshot invalidates the previous per 
admin connection snapshot. A snap^iot is a hierarchy of containers specifying the 
type, name, value and read/write attribute of values copied from the server's internal 
structures using the module API (Application Program Interface) 

Snapshots are always complete copies of the referenced resources, however, 
the returned data can be filtered by specifying thfe^desired fields in the body of a 
request. 

Response appears as SNAPSHOT: Value 
Request Definitions 

A GET without a snapshot query value is a request which automatically makes 
a new snapshot. If the snapshot is not returned by the server, then snapshots are not 
supported. 

A POST contains the default set of objects in the URL. The POST body can 
contain multiple sub URL's performing multiple SET, GET or DEL command 
operations on the set of data represented by the default URL. 

Query Options 

Options appear at the end of the URI 

example: path segment/path segment?option= "value" ,option= "value" 



URI POST Filters 

Filters specify a subset of data to be returned on each request, 
are evaluated in order with each result placed in the response. 



Multiple filters 
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Once a filter accepts a value, it is returned. 

Order of appearance when recursing is breadth first. Filter defined attributes 
replace any previous attributes settings for each filter response. The request URI is 
the default filter. New filters override the parameters defined by the request URI. 

Response Data 

All entity references follow the form [NAME = VALUE] ; 
[attribute = "value"], [attribute = "value"] 
NAME = VALUE 

NAME = VALUE; attribute = "value" 

NAME = VALUE ; attribute = " value " ; attribute = "value" 

All container references follow the form 
[NAME/] ; [attribute = "value "] , [attribute = "value "] 
NAME/ 

NAME/;attribute= "value" 

NAME/; attribute = "value" attribute = "value" 

Root Value 
/admin 

Errors in Response 

The error state for the request is always reported with each response at the end 
of the data. 

Error:(0) no error 

Error: (404) < - data not found 



* * 
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Setting Entity values 

When changing server values, the entities 1 name and their values are located 
in the request body. If a match is made on an entity name, including the URL base 
at the container level, then the value is set in the server provided the read/write 
attribute allows the set. 

base = base/container 

name = value 

/base/container/name = "value" 

There has been described herein above a novel protocol for obtaining 
administrative server data using client software which transmits a URI to the server. 
Those skilled in the art may now make numerous uses of and departures from the 
exemplary preferred embodiments disclosed herein without departing from the 
inventive concepts of the present invention. Accordingly, the present invention is to 
be defined solely by the scope of the appended Claims. 



